1. Field of the Invention
The present invention relates to a method and apparatus of deciphering parameter synchronization in a wireless communications device, and more particularly to a method and related apparatus capable of reducing signaling overhead and avoiding radio resource waste.
2. Description of the Prior Art
In a wireless communications system, in order to protect user data and signaling information from being intercepted by unauthorized devices, the prior art can perform encryption on packets transmitted between a sender and a receiver via a ciphering/deciphering method. Firstly, the sender generates keystream data via a specified algorithm based on ciphering key (CK), ciphering sequence number (SN), and other parameters or variables, and encrypts plain-text data with the keystream data to generate cipher-text data. The receiver can decipher the cipher-text data by inverse operations, so that the CK is important. Besides the CK, the ciphering SN is another important parameter used for data ciphering in the wireless communications system. The ciphering SN is formed by sequence numbers. For example, in a third generation (3G) mobile telecommunications system, the ciphering SN, called the whole SN, is composed of a 20-bit Radio Link Control Hyper Frame Number (RLC HFN) and a 12-bit Radio Link Control Sequence Number (RLC SN).
The whole SN is supposed to be carried along with the packet over the air without being ciphered, so as to maintain synchronization and accuracy of signal transmission between the sender and receiver. The whole SN is an overhead for the ciphering. To reduce the overhead, the prior art divides the whole SN into two parts, one is so-called SN embedded in a header of a packet, and the other is HFN stored in both the sender and the receiver. HFN is similar to a carrying number of SN. Each time SN wraps around its maximum representing value back to 0, HFN is incremented by one in the sender and in the receiver. For example, if SN is represented by 7 bits, which counts from 0 to 127, once SN is beyond 127, HFN is incremented by 1, and SN restarts from 0. As a result, according to SN, the sender and the receiver can timely increment HFN, so as to keep synchronization of HFN and maintain ciphering and deciphering processes.
To ensure the correct maintenance of HFN's, a sliding window can be used if the lower layer supports out of sequence delivery. There are two types of the sliding window, Push Type and Pull Type. The Push Type window is as the receiving window used in the RLC AM entity in UMTS (Universal Mobile Telecommunications System) as specified in 3GPP TS 25.322 “Radio Link Control protocol specification”. The Push Type window is advanced only when a packet corresponding to the lower edge of the window is received successfully or is informed to be discarded. When a packet with SN outside the Push Type window, the packet is discarded. The Pull Type window is as the receiving window used in the Reordering entity of HSDPA (High Speed Downlink Packet Access) in UMTS as specified in 3GPP TS 25.321 “Medium Access Control protocol specification”. The Pull Type window is advanced when a packet with SN outside the window is received and the SN is set to be the updated upper edge of the Pull Type window.
In the prior art, the window type and window size of the sliding window for the purpose of identifying HFN value for deciphering is not carefully specified. If they are not correctly used, HFN may become out of synchronization between the sender and the receiver.
For example, suppose window sizes of the receiving windows used for the HARQ (Hybrid Automatic Repeat Request) entity and the RLC entity are 10 and 16 in a receiver in UMTS, and the Pull Type window is used for a deciphering entity of the PDCP entity (Packet Data Convergence Protocol) with window size=10. If packets with SN=0˜9 are successfully received except the packet with SN=0, then the receiving window of the deciphering entity spans from 0 to 9. Now, if a packet with SN=10 is received, the receiving window of the deciphering entity is advanced to span from 1 to 10. Suppose that the missing SN=0 is due to HARQ residue error, such as NACK_to_ACK (non-acknowledgement to acknowledgement) error or DTX_to_ACK (discontinue transmission to acknowledgement) error, so that retransmission of the packet with SN=0 will be triggered by the RLC entity. Suppose that the packet with SN=0 is retransmitted after a NACK status reported by the RLC entity and is received successfully. Packet with SN=0 is then delivered to the deciphering entity. Since SN=0 is now outside the receiving window of the deciphering entity, the deciphering entity takes SN=0 to be belong to the next SN cycle, and the Pull Type window will advance the window with HFN incremented. The HFN will become out of synchronization between the Receiver and the Sender thereafter.
On the other hand, suppose that the Push Type window is used for the receiving window of the deciphering entity with window size=10 in the above example. If packets with SN=0˜9 are successfully received except the packet with SN=0, then the receiving window of the deciphering entity spans from 0 to 9. Now, if a packet with SN=10 is received, the Push Type window will neglect and discard this packet since it is outside the window. Since the RLC entity will not request for retransmission of SN=10, the window in the deciphering entity will be stalled thereafter.